This is testing ipfs/boxo#641

@aschmahmann I have a problem: before, bitswap reprovided new blocks "immediately". Now, they are sent to the reprovider.System, which reprovides them when it likes, but not immediately.

The question is:

• Whether I find a way to provide those immidiately like before (will have to port the queuing logic and call the underlying provider directly)
• Whether I change failing tests and manually call reproviding so that they pass.

Opinions?

@hsanjuan would you agree that this change in behavior seems more like a test issue than a production one? If so then what we do next seems like a matter of expediency vs maintenance.

For some of these tests it'd probably be nice to confirm that automatic providing works so we know if something breaks later. The reason this isn't working in tests is because this option https://github.com/ipfs/boxo/blob/c91cc1d5a0552c653936bd5051b6c0972d57743c/provider/reprovider.go#L226 (which is not exposed except for tests) defaults to waiting for 1 minute of uptime before providing to prevent wasted effort (e.g. if people run ipfs add but the daemon isn't running).

So there are some other options as well:

1. Remove the 1 minute timeout entirely (I'm pretty sure we wanted it for a reason, so may need to investigate more here on if removal is safe)
2. Modify how we do the tests to in some way allow setting that option (e.g. using the "Internal" section of the config, a test plugin with variables we can set in the config, etc.). It's not great that this would require building the test code / plugin into the main binary, but not necessarily so bad.

Not sure which option makes the most sense, part of me says that we should do whatever behavior we want to see normal users experience and compromise on if there's some grossness in the final binary / code related to testing (e.g. using the Internal config section or a test config section).

I can fix the failing tests by manually calling "ipfs bitswap reprovide" after adding.

What I'm wondering is whether users expect that after running "ipfs add", the new content should be provided immediately (because they add and then try to open it on the gateway etc).

There are also a number of underlying issues:

• If reprovided is set to "roots", it seems right now (in master) we are providing every block as they get added regardless.
• It seems now we are bypassing accelerated providing (in master) and announcing every block individually when adding.
• etc.

Perhaps the best is to trigger a re-provide right after adding something... but perhaps that provides other things first so it's also not perfect.

After a quick discussion: what is happening is that the reprovider has an initialDelay and that's it. Otherwise it is going to provide blocks very quickly just like it happened below, except better. So the solution is to call Reprovide on the tests that need it by hand and move on.